ドメイン駆動設計とMicroserviceでIT systemを適切なsizeに分割
どのエンジニアにも「顧客⇄開発⇄システム」のサイクル（フルサイクル）を全部担当させる ここは譲らない。
伝言ゲームの入る余地をなくすことで「service(とその未来)に最善なsystem」を作る 全部担当させるためにも…1事業/serviceを細かく分割する
microserviceという。
microservice自体は…顧客に直接価値を与えない。
microservice全体で一つの価値を顧客に提供する
ここの分割が…とても難しい
ただのsystem分割になってはいけない。
system分割では…担当するengineerの負担が下がらない。
engineerが「一つの小さいフルサイクル」に注力できる状態にする必要がある
「それだけを意識していればいい」くらい綺麗な分割をする必要がある
system分割にならないように
microservice(と担当engineer)は、microservice外のことはほぼ意識しなくて良い
具体的には
Engineer/ Operatorも、他serviceの人とのCommunicationはほぼしない
使っているIT infraもServiceによってバラバラ
さあ、そんなmicroservice分割をどうやればいいのか…？
そもそも
IT systemは「存在する業務processをsoftwareで肩代わりするもの」にすぎない
IT systemの大きさ/分割しやすさは「元々の業務Process」に大きく影響する
業務Processの基礎となる業務知識(=ドメイン知識)を起点にsystem開発をすることで、
「systemを作っても…数年・数十年変更がなさそうな部分」を想定できる
見えてきたDomainの特徴に合わせて、それを小さな単位（sub domain）に分割できる
business sideとengineer sideが共通言語を持てる
business sideの要求に対してengineer sideが背景を想像できるようになる